Data processing is often accelerated by using dedicated hardware modules known as hardware accelerators. These hardware modules are accessed and set up by the system software that runs on a processor via a programming interface, usually registers. Before a hardware accelerator can process a data stream it has to be setup by the software.
FIG. 1 shows a timing chart of conventional operation of a hardware accelerator which is described in conjunction with the block diagram of a conventional hardware accelerator module shown in FIG. 2. Hardware accelerator module 2 is accessed by a system processor, not shown, through a dedicated bus to program a set of parameters for one processing task of the hardware accelerator core 22. After writing several parameter registers, at (a), the processor triggers the hardware accelerator to start, at (b). The hardware accelerator core has to wait for a start signal (c) from register interface 21 to start processing data at time t1, as shown at (d) in FIG. 1. Now the processor has to wait until the hardware accelerator core has finished its task, which is detected at time t2 by a falling edge of the busy signal (d) returned by hardware accelerator core 22, before it can program a new parameter set for processing a next data block of a data stream. It is obvious that these downtimes of the accelerator core significantly limit the throughput of the accelerator module.
Currently, parameters for the hardware accelerator are either directly programmed by the system software or stored in a separate RAM. The first case requires the hardware accelerator to be programmed after each processing cycle. The use of a separate parameter RAM is intended to reduce bus load under different recurrent processing conditions. When using a separate parameter RAM, such as e.g. described in U.S. Pat. No. 6,842,844, the software can program parameters for different processing conditions in advance, and the hardware accelerator may use these sets afterwards for several times. However, the hardware accelerator has still to be programmed after each processing cycle. Moreover, employing a separate parameter RAM is not transparent for the system software, which is to say that the processor has still to tell the hardware accelerator which parameter set to use.
An object of the invention is to reduce downtimes and increase data throughput of hardware accelerators. Another object of the invention is to reduce the risk of processor overload in a processor which drives several hardware accelerators.